Skip to content

sequential: use os.OpenFile with O_FILE_FLAG_SEQUENTIAL_SCAN on Go 1.26+#216

Merged
thaJeztah merged 1 commit into
moby:mainfrom
tonistiigi:sequential-1.26
Jun 5, 2026
Merged

sequential: use os.OpenFile with O_FILE_FLAG_SEQUENTIAL_SCAN on Go 1.26+#216
thaJeztah merged 1 commit into
moby:mainfrom
tonistiigi:sequential-1.26

Conversation

@tonistiigi
Copy link
Copy Markdown
Member

Go 1.26 adds support for passing Windows file flags via os.OpenFile, eliminating the need to call windows.CreateFile directly. Split the implementation into build-tagged files: go1.26+ uses os.OpenFile with the new O_FILE_FLAG_SEQUENTIAL_SCAN open flag, while older versions retain the manual CreateFile approach.

Also bump golang.org/x/sys to v0.37.0 (provides the new constant) and update the minimum Go version to 1.24.

https://go-review.googlesource.com/c/go/+/699415
https://go-review.googlesource.com/c/go/+/724621

@thaJeztah
Copy link
Copy Markdown
Member

# golang.org/x/sys/windows
Error: C:\Users\runneradmin\go\pkg\mod\golang.org\x\sys@v0.37.0\windows\security_windows.go:1318:39: undefined: unsafe.SliceData
Error: C:\Users\runneradmin\go\pkg\mod\golang.org\x\sys@v0.37.0\windows\security_windows.go:1321:39: undefined: unsafe.SliceData
Error: C:\Users\runneradmin\go\pkg\mod\golang.org\x\sys@v0.37.0\windows\security_windows.go:1324:40: undefined: unsafe.SliceData
Error: C:\Users\runneradmin\go\pkg\mod\golang.org\x\sys@v0.37.0\windows\security_windows.go:1327:40: undefined: unsafe.SliceData

Looks like we need to bump the module to go1.20 as minimum;

Screenshot 2026-04-01 at 23 38 23

@thaJeztah
Copy link
Copy Markdown
Member

Oh! Probably the other module that is (moby/sys/mount), which is tested against both the version specified in go.mod and against latest in the branch;

MINGW64_NT-10.0-20348 runnervm6wf0k 3.6.6-1cdd4371.x86_64 2026-01-15 22:20 UTC x86_64 Msys
/usr/bin/sh: line 1: sudo: command not found
/usr/bin/sh: line 1: sudo: command not found
echo 'replace github.com/moby/sys/mountinfo => ../mountinfo' | cat mount/go.mod - > mount/go-local.mod

@tonistiigi tonistiigi force-pushed the sequential-1.26 branch 3 times, most recently from 694e9c8 to a8ce7d7 Compare April 2, 2026 05:20
@tonistiigi
Copy link
Copy Markdown
Member Author

Looks like we need to bump the module to go1.20 as minimum;

I had already bumped to 1.24 (via x/sys update that had this as minimum). This is the 1.18 hacks.

I removed my previous attempt to patch the 1.18 workarounds and removed it from CI like I initially did in #214 . I've already spent way too much time on these 1.18 exceptions that nobody needs.

@crazy-max
Copy link
Copy Markdown
Member

image

We should remove the required checks in branch protection. Makes little sense to keep them anyway.

Go 1.26 adds support for passing Windows file flags via os.OpenFile,
eliminating the need to call windows.CreateFile directly. Split the
implementation into build-tagged files: go1.26+ uses os.OpenFile
with the new O_FILE_FLAG_SEQUENTIAL_SCAN open flag, while older
versions retain the manual CreateFile approach.

Also bump golang.org/x/sys to v0.37.0 (provides the new constant)
and update the minimum Go version to 1.24.

Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

)

func openFileSequential(name string, flag int, perm os.FileMode) (*os.File, error) {
return os.OpenFile(name, flag|windows.O_FILE_FLAG_SEQUENTIAL_SCAN, perm)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

once we drop support for < go1.26, we should define this as a local const, so that we no longer have a dependency on "golang.org/x/sys/windows"

@thaJeztah thaJeztah merged commit 8d586cf into moby:main Jun 5, 2026
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants